I've never been a big fan of the XDG spec, but was willing to add support for XDG for those that wanted it.

I don't see a compelling reason to make the XDG location the default other than as a statement of support for the spec.

I'll need a more compelling reason than a statement of support to consider this change.

I've never been a big fan of the XDG spec

I don't really understand this perspective. Is it a concern related to burden on you as an OSS maintainer?

From a user's / developer's perspective, the XDG Base Dirs Spec solves a few problems relating to cleanly organizing program data, configs, and caches, while not creating any other problems, or real added complexity.

If you, for some reason, do want all of your program config files and data to live in your $HOME (or other non-standard) directory, you can do that with the $PROGRAM_DIR variables provided by many programs, vit included. But I don't know many people that actively desire this crowded $HOME behavior -- it's reminiscent of some "Tragedy of the Commons" discussions from my college econ classes. If every program "takes advantage" of $HOME, $HOME becomes way less useful.

I actively don't want a ~/.vit directory to exist. If every program I installed did this, my $HOME would be completely unusable. Having a clean $HOME, and knowing exactly where to go to find / edit config files, saves me TONS of time and lets me work more effectively.

Here's a longer piece (not written by me) about why I value this spec: https://maex.me/2019/12/the-power-of-the-xdg-base-directory-specification/

This changeset would provide default support for people who like a clean home directory and want to use XDG. It maintains backwards compatibility for those who have set up ~/.vit as the config directory, and still allows the user to define arbitrary config locations with $VIT_DIR.

Everyone knows that feeling, you type an ls -la in your home directory, or something similar which lists also hidden files and you get back a huge list of files where you have no idea what it is, where it came from and what it does.

This describes the central issue with XDG as a philosophy IMO -- it starts with "it doesn't feel good to see a lot of files in HOME". That is a personal perspective, not a fact. My personal experience of my HOME directory is nothing like that. As a matter of fact, my personal experience with XDG is mostly negative:

• Annoyance when I expect to find a file directly in HOME, and instead have to go hunting for it.
• Annoyance at another level of directories to navigate when I'm at CLI and trying to get to a program's config directory.

I definitely understand that people can have difference experiences and want things organized in a specific way, which is why XDG support was added to VIT -- to allow those who prefer that organizational system an easy way to achieve it.

But to me, saying XDG is better than the classic method is similar to saying Emacs is better than Vim -- there is no 'better', it's personal preference.

Now, show me a fact-based argument (e.g. these three surveys show that 85% of people prefer the XDG organization philosophy, or, this study shows that when people switch to using XDG it reduces their frustration and improves productivity by X%), and I can probably be moved. But "I don't know many people that actively desire this crowded $HOME behavior" is anecdotal.

Finally, I think changing default behavior without a really compelling reason generally creates a bad user experience. Right now the people that use XDG know they need to take one extra step, and everybody else like me finds the config where they expect it.

Just as a point of reference, I make absolutely no effort to control where programs put stuff in HOME, and here's the distribution of HOME dotfiles/dotdirs to XDG .config files/dirs on my personal machine:

[:~] $ ls -1 .config/ | wc -l
130
[:~] $ ls -1 -d .* | wc -l
134

So it hardly seems like XDG is a clear winner in the spec wars ;)

I think changing default behavior without a really compelling reason generally creates a bad user experience. Right now the people that use XDG know they need to take one extra step, and everybody else like me finds the config where they expect it.

Just to clarify, this would not change the behavior for any current user. This only impacts people who don't have an existing config (so, people downloading it for the first time on a machine). If they do have an existing config in ~/.vit, that is used. See the documentation in CUSTOMIZE.md.

"it doesn't feel good to see a lot of files in HOME".

The more important aspect is that it makes me less organized, and less effective on my machine. XDG Base Dir spec is an organizational structure, just like the standard directories of the linux filesystem are an organizational structure. If you're looking for bootloader files, you go to /boot. Devices are in /dev. Program configs are in $XDG_CONFIG_HOME.

Now, show me a fact-based argument (e.g. these three surveys show that 85% of people prefer the XDG organization philosophy, or, this study shows that when people switch to using XDG it reduces their frustration and improves productivity by X%), and I can probably be moved.

Unlikely to happen, lol

For another point of reference: I make an effort to keep $HOME clean.

➜ ls -1 -d ~/.config/* | wc -l
226

➜ ls -1 -d ~/.* | wc -l
38

Anyways, thanks for loosely supporting the XDG spec.

The more important aspect is that it makes me less organized, and less effective on my machine. XDG Base Dir spec is an organizational structure, just like the standard directories of the linux filesystem are an organizational structure. If you're looking for bootloader files, you go to /boot. Devices are in /dev. Program configs are in $XDG_CONFIG_HOME.

Yep, I understand this reasoning, which is why support for XDG is in VIT.

Just to clarify, this would not change the behavior for any current user.

With the exception of a previous user of VIT installing it on a new machine (you can sync Taskwarrior after all), and then not being able to find their config where they expect it. But I do see your point that many use cases for existing users would remain undisturbed in many circumstances.

For another point of reference: I make an effort to keep $HOME clean.

Bit of a bummer that you can't get that number lower in HOME -- are those projects that have zero XDG support?

With the exception of a previous user of VIT installing it on a new machine (you can sync Taskwarrior after all), and then not being able to find their config where they expect it.

If everyone was using the XDG spec, porting all of your configs to a new machine should be as easy as copying over $XDG_CONFIG_HOME. I wrote a tool (many ages ago) https://github.com/alichtman/shallow-backup to help solve this problem.

(you can sync Taskwarrior after all)

This all lives here (on my machine):

$ ls ~/.config/task
 hooks
 backlog.data
 completed.data
 pending.data
 taskrc
 undo.data

So if I move over to a new machine, I'd have to find / copy my taskwarrior data anyways. Going to a different place to find my vit config seems frustrating.

Bit of a bummer that you can't get that number lower in HOME -- are those projects that have zero XDG support?

Here's an excerpt from my zshenv: https://github.com/alichtman/dotfiles/blob/master/.zshenv#L41-L147

Yeah, for the most part. Some are necessary (like ~/.zshenv), and others are unfixable for me as a user:

$ ls ~/.* -d
 /home/alichtman/.1password/
 /home/alichtman/.BurpSuite/
 /home/alichtman/.cache/
 /home/alichtman/.config/
 /home/alichtman/.cups/
 /home/alichtman/.dotnet/
 /home/alichtman/.eclipse/
 /home/alichtman/.ghc/
 /home/alichtman/.ghidra/
 /home/alichtman/.gnupg/
 /home/alichtman/.java/
 /home/alichtman/.lldb/
 /home/alichtman/.local/
 /home/alichtman/.mozilla/
 /home/alichtman/.msf4/
 /home/alichtman/.nv/
 /home/alichtman/.pki/
 /home/alichtman/.rpmdb/
 /home/alichtman/.rvm/
 /home/alichtman/.ssh/
 /home/alichtman/.steam/
 /home/alichtman/.var/
 /home/alichtman/.vmware/
 /home/alichtman/.vscode/
 /home/alichtman/.wine/
 /home/alichtman/.zoom/
 /home/alichtman/.ctags
 /home/alichtman/.profile
 /home/alichtman/.pypirc
 /home/alichtman/.reportbugrc
 /home/alichtman/.secrets
 /home/alichtman/.steampid ⇒ /home/alichtman/.steam/steam.pid
 /home/alichtman/.Xauthority
 /home/alichtman/.xinitrc
 /home/alichtman/.Xresources
 /home/alichtman/.yarnrc
 /home/alichtman/.zshenv

1Password, for example, creates an empty directory in $HOME that kills my soul a bit every time I see it.

$ ls ~/.1password
<NOTHING>

See this wiki section for a more complete answer about support / lack of support: https://wiki.archlinux.org/title/XDG_Base_Directory#Support

If everyone was using the XDG spec, porting all of your configs to a new machine should be as easy as copying over $XDG_CONFIG_HOME

Except I don't just take all my config wholesale anyways when I switch to a new machine. If I never touched a program's config, I don't want to take it, which means I'm selective about which configs I port, which makes location a LOT less important.

Going to a different place to find my vit config seems frustrating.

Yes, I experience this when I expect my Neovim config to be at .nvim, but instead, it is frustratingly placed at .config/nvim ;)